<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
  <title>Boost Library Submission Process</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <link rel="icon" href="/favicon.ico" type="image/ico" />
  <link rel="stylesheet" type="text/css" href=
  "/style-v2/section-development.css" />
  <!--[if IE 7]> <style type="text/css"> body { behavior: url(/style-v2/csshover3.htc); } </style> <![endif]-->
</head><!--
Note: Editing website content is documented at:
https://www.boost.org/development/website_updating.html
-->

<body>
  <div id="heading">
    <!--#include virtual="/common/heading.html" -->
  </div>

  <div id="body">
    <div id="body-inner">
      <div id="content">
        <div class="section" id="intro">
          <div class="section-0">
            <div class="section-title">
              <h1>Boost Library Submission Process</h1>
            </div>

            <div class="section-body">
              <p>This page describes the process a library developer goes
              through to get a library accepted by Boost.</p>

              <p>See the <a href="requirements.html">Boost Library
              Requirements and Guidelines</a> page for issues of content.</p>

              <h3>Steps for getting a library accepted by Boost:</h3>

              <ul class="toc">
                <li>
                  <a href="#Learn">1. Learn about Boost</a>
                </li>

                <li>
                  <a href="#interest">2. Determine interest</a>
                </li>

                <li>
                  <a href="#Development">3. Start Development</a>
                </li>

                <li>
                  <a href="#Refinement">4. Refinement</a>
                </li>

                <li>
                  <a href="#Seconded">5. Getting seconded for review</a>
                </li>

                <li>
                  <a href="#Seeking">6. Seek a Review Manager</a>
                </li>

                <li>
                  <a href="#Review">7. Formal Review</a>
                </li>

                <li>
                  <a href="#SitePosting">8. Web site posting</a>
                </li>

                <li>
                  <a href="#People">9. People page</a>
                </li>

                <li>
                  <a href="#Lifecycle">10. Lifecycle</a>
                </li>
              </ul>

              <h2><a name="Learn" id="Learn"></a>1. Learn about Boost</h2>

              <p>Follow posts on the <a href="/community/groups.html#main">main
              developers mailing list</a> for a while, or look through the
              <a href="/community/groups.html#archive">archives</a>. Explore
              the <a href="/">web site</a>. Learn the <a href=
              "requirements.html">Requirements</a>. Read the rest of this
              page to learn about the process. Search the web to get an idea
              of the commitment required to get a library into Boost.
              </p>

              <p>There is a culture associated with Boost, aimed at
              encouraging high quality libraries by a process of discussion
              and refinement. Some libraries get past community review
              in less than two years from first concept, but most take longer,
              sometimes a lot longer. Five to ten years to get a library past
              review and into Boost is not unheard of, and you should prepare
              yourself for the personal investment required.</p>


              <h2><a name="interest" id="interest"></a>2. Determine
              interest</h2>

              <p>While participation in reviews for other submissions is not a
              prerequisite for submitting a library to Boost, it is highly
              recommended; it will acquaint you with the process and the
              emotional demands of a formal review. There's nothing that quite
              deflates the ego like having brilliant members of the C++
              community critiquing your work, but, alas, it's worth it!</p>

              <p>Potential library submitters should be careful to
              research the prior art before beginning to design a
              new library. Unfortunately, now and then folks arrive at Boost
              with a new library into which they have invested many hours, only
              to find that Boost already has that functionality, and sometimes
              has had it for years. Candidates should also research libraries being
              developed by others intended for Boost - if you have an itch
              to scratch, often so have had others and collaboration
              developing their library is usually considerably more efficient
              than going at it alone.</p>

              <p>Potential library submitters should also be careful to
              publicise, canvas for, and gauge interest in their library,
              ideally before beginning it, but certainly before submitting it
              for review. Even a superbly designed library can fail review if
              there isn't enough interest in the subject matter; We can only
              review libraries with enough appeal to form a viable peer
              review. Ensuring that enough people are interested in your
              potential library goes a long way to ensure that.</p>

              <p>There are many places to publicise and canvas for a library.
              The Boost developers <a href="/community/groups.html">mailing
              list</a> and the <a href="http://blincubator.com">Boost Library
              Incubator</a> ought to be your first stop in gauging interest
              in a possible new C++ library. Be prepared to pivot your design
              and focus until your proposed library finds traction. Other
              places useful for gauging interest in a library might be <a href=
              "https://www.reddit.com/r/cpp/">Reddit/r/cpp</a>.</p>

              <p>A message to the Boost developers mailing list
              might be as simple as "Is there any interest in a
              library which solves Travelling Salesperson problems in linear
              time?"</p>

              <p>A bit of further description or snippet of code may be
              helpful. By the way, the preferred format for messages on the
              mailing list is plain text; not rich text, HTML, etc.</p>

              <p>Avoid posting lengthy descriptions, documentation,
              or code to the mailing list, and, please, no attachments.
              The best place to provide lengthy material is via. a web link.
              Project hosting services such as sourceforge, github, google
              code, and bitbucket serve well for this purpose.</p>


              <h2><a name="Development" id="Development"></a>3. Start
              Development</h2>

              <p>If response to an initial query indicates interest, then
              by all means make your library publicly available if you haven't
              already done so.</p>

              <p>Please commit your code to a version control system such as
              Git, and make your documentation available in HTML format on
              a public website such as Github. An issue tracker such as the one
              provided by Github is also highly recommended.</p>

              <p>Your library should contain material as if it were on the
              boost.org web site. The closer your library reflects the
              final directory structure and format of the web site, the
              better. This makes it possible for reviewers to simply copy
              your code into the Boost distribution for testing.</p>

              <p>Please verify that your library compiles and runs under
              at least two compilers. This flushes out obvious portability
              problems.</p>

              <p>It is recommended that you release your code under the Boost
              Software License; see the <a href=
              "requirements.html">Requirements</a> page for more
              information.</p>

              <p>You can receive preliminary feedback and reviews by
              submitting your library to the <a href=
              "http://blincubator.com">Boost Library Incubator</a>.</p>


              <h2><a name="Refinement" id="Refinement"></a>4. Refinement</h2>

              <p>Discuss, refine, rewrite. Repeat until satisfied.</p>

              <p>The exact details of this process varies a lot. Usually it
              is public, on the mailing list, but frequently discussion
              happens in private emails. For some libraries the process is
              over quickly, but for others it goes on for months. It's
              often challenging, and sometimes veers into completely
              unexpected directions.</p>

              <p>The <a href="/community/groups.html#archive">archive</a> of
              past messages is one way to see how this process worked for
              other Boost libraries.</p>

              <p>To get an idea of best practices with some samples of script
              and code in existing Boost libraries, see the
              <a href="https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook">
              Best Practices Handbook</a> on the Boost wiki.</p>


              <h2><a name="Seconded" id="Seconded"></a>5. Getting seconded
              for review</h2>

              <p>When you feel that your library is ready for entry into Boost,
              you need to find at least one member (but preferably several) of
              the Boost community who is willing to publicly endorse your
              library for entry into Boost. A simple method of achieving this
              is to post to <a href="/community/groups.html">the Boost
              developers mailing list</a> a short description of your
              library, links to its github and documentation, and a request for
              endorsements.</p>

              <p>It is expected that those who endorse a library for review
              will have performed at least a cursory check of the library's
              suitability for Boost in terms of documentation, fit with
              the rest of Boost and usefulness. A public endorsement of a
              library for review means that from an initial glance, they
              believe that the library has a reasonable chance to be accepted
              during a formal review. The expectation is that these endorsers
              will themselves review of the library during formal review
              period, though this is not binding.</p>

              <p>Once you have a list of people who have publicly endorsed
              your library for review, email <a
              href="/community/reviews.html#Wizard">the Review Wizards</a>
              to request that your library be added to <a
              href="/community/review_schedule.html">the review queue</a>
              where the following information will be shown:</p>

              <ul>
                <li>Submission</li>
                <li>Submitter</li>
                <li>Links to Source (GitHub), Documentation (HTML website)
                and any Incubator entry</li>
                <li>Names of members who endorse this submission for review</li>
                <li>Review Manager</li>
                <li>Review Dates</li>
              </ul>


              <h2><a name="Seeking" id="Seeking"></a>6. Seek a Review
              Manager</h2>

              <p>In order to schedule a formal review, the author must find a
              capable volunteer to manage the review. This should be someone
              with knowledge of the library domain, and experience with the
              review process. See <a href="/community/reviews.html">Formal
              Review Process</a> for the responsibilities of the review
              manager.</p>

              <p>Authors can find community members interested in managing
              reviews through discussion of the library on the developer
              list. If no one steps forward to volunteer to manage the
              review, it is appropriate to contact an experienced Boost
              member who showed interest in the library. Be considerate that
              managing a review is a serious commitment; for this reason,
              it's better to contact the member off-list.</p>

              <p>If you cannot find a review manager after 3 weeks using the
              means above, and your submission is targeting eventual
              standardization, there is a list of Boost regulars who are also
              WG21 committee members who have volunteered to act as review
              managers in such cases.  Please try them in the order listed.
              They are: Zach Laine, Micheal Caisse, Matt Calabrese, Edward
              Diener, Louis Dionne, Vinnie Falco, Glen Fernandes, and David
              Sankel.</p>

              <p>Once a potential review manager has been identified, <a
              href="/community/reviews.html#Wizard">contact the
              review wizards</a> for approval. The wizards approve review
              managers based on their level of participation in the Boost
              community.</p>

              <p>The review wizards will coordinate with both the author and
              review manager to schedule a date convenient for both.</p>

              <p>See <a href="/community/reviews.html">Formal Review
              Process</a> for details.</p>


              <h2><a name="Review" id="Review"></a>7. Formal Review</h2>

              <p>Before your formal review begins, double-, triple-, and
              quadruple-check your library. Verify that every code example
              works, that all unit tests pass on at least two compilers on at
              least two major operating systems, and run your documentation
              through a spelling and grammar checker.</p>

              <p>Please do not modify your library on its master branch
              during a review. Instead, modify a separate develop branch in
              response to feedback and reviews. For bigger ticket items of
              work, open issues on your issue tracker so interested people can
              track the fixing of specific issues raised.</p>

              <p>The review manager will consider all the reviews made by
              members of the community and arrive at a decision on
              whether your library is rejected, conditionally accepted or
              unconditionally accepted. They will post a report summarising
              the decision publicly. If conditions are attached to
              acceptance, you will need to implement those conditions or
              else undergo an additional formal review.</p>


              <h2><a name="SitePosting" id="SitePosting"></a>8. Boost web site
              posting</h2>

              <p>Once an accepted library is ready for inclusion on the Boost
              web site, the submitter is typically given Boost repository
              write access, and expected to check-in and maintain the library
              there. Contact the moderators if you need write access or
              direct use of the repository isn't possible for you.</p>


              <h2><a name="People" id="People"></a>9. People page</h2>

              <p>If the boost.org web site doesn't already have your capsule
              biography and picture (optional, with not-too-serious pictures
              preferred!), please send them to the Boost webmaster. It is up
              to you as to whether or not the biography includes your email
              address or other contact information. The preferred picture
              format is .jpg, but other common formats are acceptable. The
              preferred image size is 500x375 but the webmaster has photo
              editing software and can do the image preparation if
              necessary.</p>


              <h2><a name="Lifecycle" id="Lifecycle"></a>10. Lifecycle</h2>

              <p>Libraries are software; they lose their value over time if
              not maintained. Postings on the Boost developers or users
              mailing lists can alert you to potential maintenance needs;
              please plan to maintain your library over time. If you no
              longer can or wish to maintain your library, please post a
              message on the Boost developers mailing list asking for a new
              maintainer to volunteer and then spend the time to help them
              take over.</p>

              <p>Orphaned libraries will be put in the care of the <a href=
              "https://svn.boost.org/trac/boost/wiki/CommunityMaintenance">Community
              Maintenance Team</a>.</p>
            </div>
          </div>
        </div>
      </div>

      <div id="sidebar">
        <!--#include virtual="/common/sidebar-common.html" -->
        <!--#include virtual="/common/sidebar-development.html" -->
      </div>

      <div class="clear"></div>
    </div>
  </div>

  <div id="footer">
    <div id="footer-left">
      <div id="revised">
        <p>Revised $Date$</p>
      </div>

      <div id="copyright">
        <p>Copyright Beman Dawes, 2000.</p>
      </div><!--#include virtual="/common/footer-license.html" -->
    </div>

    <div id="footer-right">
      <!--#include virtual="/common/footer-banners.html" -->
    </div>

    <div class="clear"></div>
  </div>
</body>
</html>
